• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    METHOD OF EXECUTING A FINANCIAL TRANSACTION THROUGH UNSECURED PUBLIC TELECOMMUNICATION INFRASTRUCTURE, COMMUNICATIONS DEVICE TO FACILITATE THE EXECUTION OF A FINANCIAL TRANSACTION THROUGH UNSECURED PUBLIC TELECOMMUNICATION INFRASTRUCTURE AND CARD. A method of executing a financial transaction over an unsecured public telecommunications infrastructure, comprising collecting data relating to a specific type of financial transaction; the formation of a transaction token that includes data collected and/or data derived from the collected data; transaction token encryption; creating a transaction protocol message that embeds the encrypted transaction token as dependent on a selected transport channel over which the message is to be transmitted; and transporting the financial transaction protocol message through the use of the selected transport channel and via an insecure public telecommunication infrastructure to a destination where the financial transaction protocol message will continue to be processed.
    公开号:BR112013011299B1
    申请号:R112013011299-9
    申请日:2010-11-10
    公开日:2021-05-18
    发明作者:Alex D. Ibasco；Patrick B. Posadas；Vincent C. Co；William Emmanuel S. Yu
    申请人:Einnovations Holdings Pte. Ltd.；
    IPC主号:
    专利说明:

    FIELD OF THE INVENTION
    [001] The invention relates to a method of executing a financial transaction through an Unsecured Public Telecommunications infrastructure and equipment for such. The invention is particularly suitable for a mobile phone that is operating in a substantially identical manner to current Point of Sale ("POS") payment terminals used to make debit and credit card transactions. HISTORY OF THE INVENTION
    [002] The following discussion of the background of the invention is intended to facilitate the understanding of the present invention. However, it should be noted that the discussion is not an acknowledgment or admission that any material mentioned has been published, is known or part of general common knowledge in any jurisdiction as of the priority date of the request.
    [003] Existing Payment Security Application Module (“PSAM”) transactions work on the assumption that there is a secure connection between the terminal and the administrative systems of the receiving financial institution. Consequently, the only security mechanism used in these transactions is encryption of the personal identification number (“PIN”) block.
    [004] Although the assumption has some merit in the case of terminals with exclusive lines and routing structures for the receiving financial institution, it is still possible to intercept transmissions that flow through this type of architecture.
    [005] In contrast, the applicant developed the present invention based on the contrary assumption that there is no secure connection between a terminal and the administrative system. Consequently, the depositor's invention allows the use of an unsecured public telecommunications infrastructure for processing PSAM transactions, such as the short message service (“SMS”). The use of SMS infrastructure and protocols to process financial transactions, however, poses more problems because of the limited amount of data that can be used to communicate those transactions, and its inherent resilience associated with the typically high data carriers of cryptography.
    [006] At the same time, the hardware specifications for running PSAM applications were defined in the Terminal Architecture for PSAM Application, published by Europay International, PBS A/S and Visa International Service Association in 2000. However, in the manner it is contemplated in this document, PSAM is a standardized endpoint with an architecture-independent structure.
    [007] The result was the development of specific point-of-sale terminals, with exclusive hardware. In the case of mobile device point-of-sale terminals, the PSAM chip handles all PSAM functionality, while a separate SIM card handles the transport of PSAM-generated data over the wireless network.
    [008] As a result of this architecture:
    [009] The mobile device point-of-sale terminal form factor must be large enough to accommodate the two separate chips (the PSAM chip and the SIM card); and
    [0010] Mass consumer SIM devices, such as mobile phones, do not qualify to be used for PSAM application processes.
    [0011] This last restriction, combined with the high cost of dedicated PSAM hardware, has stifled the adoption of PSAM by merchants to process financial transactions.
    [0012] Prior art knowledge US 2008/0091614 A1 and WO 2007/053117 A1. SUMMARY OF THE INVENTION
    [0013] Throughout this document, unless otherwise indicated otherwise, the terms "comprise", "consist of" and the like shall be considered as non-exhaustive, or, in other words, mean "including, between others".
    [0014] According to a first aspect of the present invention there is a method of executing a financial transaction through an unsecured public telecommunications infrastructure, comprising the steps of:
    [0015] collection of data related to a specific type of financial transaction;
    [0016] formation of a transaction token that includes collected data and/or data derived from the collected data;
    [0017] transaction token encryption;
    [0018] creation of a transaction protocol message that incorporates the encrypted transaction token as dependent on a selected transport channel over which the message is to be transmitted; and
    [0019] transport of the financial transaction protocol message through the use of the selected transport channel and through an insecure public telecommunication infrastructure to a destination where the financial transaction protocol message will continue to be processed.
    [0020] The step of collecting data related to a specific type of transaction may also include the sub-step of collecting authentication data, which are later encrypted, the transaction token formed later, including the encrypted authentication data. Transaction token data can also be formatted and/or encrypted.
    [0021] The step of collecting data related to a specific type of financial transaction may also include obtaining data in at least one of the following ways: from files stored on a device used to obtain the data; a data reader associated or integrated with the device used to obtain the data; from a client, through the user interface of the device used to obtain the data. Data obtained in this way can include a set of transaction rules applicable to the type of financial transaction.
    [0022] The transaction token can also be populated as needed for the selected transport channel.
    [0023] The method can also include the step of calculating a session key, which is then used to encrypt the transaction token during the transaction token encryption step.
    [0024] The selected transport channel can be General Packet Radio System (“GPRS”) or SMS.
    [0025] When the selected transport channel is GPRS, the step of creating a transaction token can include the sub-steps of:
    [0026] append an administration token record data value to the transaction token; and
    [0027] pad the transaction token with null values until the changed transaction token is a multiple of 8 bytes.
    [0028] Similarly, the step of encrypting the transaction token also includes the sub-steps of calculating a message authentication code session key and encrypting the changed and filled transaction token using the session key. message authentication code.
    [0029] And also, when the selected transport channel is GPRS, the step of creating a financial transaction protocol message can include the sub-step of creating a serial key number, and where the financial protocol message created from that way comprises the serial key number, the transaction token and a message authentication code session key.
    [0030] When the selected transport channel is SMS, the transaction token construction step also includes the sub-steps of determining a filling counter and a message counter, and appending the filling counter and the message counter. message to message. The transaction token encryption step can also include the transaction token encryption sub-step using an encryption key based on 3GPP TS 03.48 specifications.
    [0031] And even when the selected transport channel is SMS, the step of creating a financial transaction protocol message can include the sub-step of prefixing the encrypted transaction token with an SMS header.
    [0032] According to a second aspect of the present invention, there is a communications device to facilitate the execution of a financial transaction through an unsecured public telecommunications infrastructure, such communications device being operable to run software stored on it or on media removable in data communication and control with the device, for
    [0033] collect data related to a specific type of financial transaction;
    [0034] form a transaction token that includes collected data and/or data derived from the collected data;
    [0035] encrypt the transaction token;
    [0036] create a financial transaction protocol message that embeds the encrypted transaction token as dependent on a selected transport channel over which the message is to be transported; and
    [0037] transport the financial transaction protocol message using the selected transport channel and through the insecure public telecommunication infrastructure to a destination where the financial transaction protocol message will continue to be processed.
    [0038] Collected data may include authentication data. The transaction token can enclose authentication data in encrypted form.
    [0039] The communications device may also include a reader to read information stored in external devices.
    [0040] Preferably, the communications device is operable to communicate via one or more of the following transport channels: GPRS; SMS.
    [0041] According to a third aspect of the present invention, there is a card comprising at least one integrated circuit, having a similar size and shape to the Subscriber Identity Module ("SIM") card, in which, when the card is received within a device with a SIM card interface, executable software stored on a memory media of the at least one integrated circuit, when running, is able to communicate with the software stored on the device, thus allowing the device to provide both SIM and PSAM functionality for a device user.
    [0042] The device can manage to be operated only as SIM or PSAM at any point in time, and the communication between the software stored in the memory medium and the software stored in the device takes place through a logical communications channel. BRIEF DESCRIPTION OF THE DRAWINGS
    [0043] The invention will now be described by way of examples only, with reference to the accompanying drawings, in which:
    [0044] Figure 1 is a flowchart of a first embodiment of the present invention.
    [0045] Figure 2 is a general hardware schematic used in the first embodiment of the present invention.
    [0046] Figure 3 is a graphical representation of a transaction token as used in the present invention.
    [0047] Figure 4 is a first flowchart of a second embodiment of the present invention.
    [0048] Figure 5 is a second flowchart of a second embodiment of the present invention.
    [0049] Figure 6 is a general schematic of a communications device that incorporates both SIM and PSAM functionality. PREFERRED ACHIEVEMENTS OF THE INVENTION
    [0050] According to a first embodiment of the invention, there is a method of performing a financial transaction through an unsecured public telecommunication infrastructure 100. A flowchart of the method 100 is shown in Figure 1.
    [0051] The underlying entities operating in the method comprise a terminal unit 10 and an administrative processing system 12. A payment application 14 is a program executable in the terminal unit 10. In this configuration, the payment application 14 is also stored in memory. 16 of terminal unit 10.
    [0052] In addition to the executable code that forms the basis for payment application 14, payment application 14 also includes a plurality of data files 18. Data files 18 store data needed by payment application 14 during different payment sessions. application/transaction. The types of data stored in the plurality of data files 18 include:
    [0053] Security data;
    [0054] Connection data; and
    [0055] Transaction data.
    [0056] In the case of transaction data, typical information stored includes the International Mobile Equipment Identity of terminal unit 10; the processing rules for the different possible transactions to be processed by the payment application 14; the unique identification code of the administrative processing system 12; and a temporary copy of the last transaction token.
    [0057] Payment application 14 also maintains a transaction log 20. Transaction log 20 contains selected details of at least three previous transactions processed by payment application 14 (including selected details of any response issued by administrative processing system 12 ). This selected information allows the payment application 14 to confirm which transactions have taken place, for the purpose of dispute resolution, and also as a means of facilitating the reversal of a past transaction.
    [0058] It should be noted that to avoid duplication, any transaction retry request made by payment application 14 is not separately recorded in transaction log 20. When a transaction retry request is made, an associated retry counter to request is incremented as record of that request.
    [0059] Transaction log 20 is a read-only data file. Transaction register 20 keeps data related to previous transactions in First In, First Out schema.
    [0060] The method of this first embodiment is now described as follows.
    [0061] The user navigates through the terminal unit user interface in order to instruct the terminal unit that a new financial transaction is being created (Step 102).
    [0062] When an indication is made that a new financial transaction is to be created, the terminal unit asks the user what the type of the new financial transaction is (Step 104). The user has the option to specify one of the following types of financial transactions:
    [0063] Transaction request;
    [0064] Transaction replay request; and
    [0065] Transaction rollback request.
    [0066] As the form of each of these types of financial transactions is dictated by the transport channel used, the method of this embodiment of the invention will now be discussed purely in the context of a transaction request.
    [0067] After specifying that the new financial transaction is a transaction request, the terminal unit works to collect data related to the transaction (Step 106). This information comes from three sources:
    [0068] The terminal unit itself, including its file systems;
    [0069] The customer's credit/debit card; and/or
    [0070] The client(s) themselves.
    [0071] A required piece of information is the user's PIN.
    [0072] The need for and the method by which a PIN is entered are determined by the processing rules encapsulated in the terminal unit's stored file systems (Step 108). In situations where a PIN needs to be entered, there are two methods for entering a PIN contemplated in this embodiment of the invention:
    [0073] Insertion through the terminal unit; or
    [0074] Insertion via an SMS Toolkit (“STK”) session.
    [0075] In this embodiment, the processing rules specify that a PIN must be entered via the terminal unit.
    [0076] When PIN entry is via the terminal unit, the user simply enters the PIN using the provided user interface. The PIN is then formatted as an ISO-0 PIN block (Step 110). The PIN Block is then encrypted using a PIN key for transmission to the administrative processing system. (Step 112)
    [0077] Once all the necessary and relevant information is obtained, the information is gathered and used to form a transaction token (Step 116). However, before the transaction token can be properly constructed, the administrative financial transaction transport channel must be determined (Step 114). The transport channel can be any insecure public telecommunication infrastructure capable of processing messages.
    [0078] Once the transport channel has been determined, an initial transaction token is created. The initial transaction token comprises three elements:
    [0079] A Message Type Identifier. The message type identifier indicates the type of message being sent (for example, a transaction request; a transaction retry request; or a transaction rollback request);
    [0080] A Bitmap. The bitmap indicates which data elements are contained in the message.
    [0081] The Data Elements. These are the values of the data elements contained in the bitmap.
    [0082] This structure is shown graphically in Figure 3.
    [0083] The person skilled in the art will note that the structure used to define the bitmap is primarily regulated by ISO 8583:1987. Consequently, the structure will not be defined in more detail here.
    [0084] The initial transaction token is then populated as appropriate for the selected transport channel (Step 118). This can also include adding multiple data elements to the transaction token. The end result is a changed transaction token.
    [0085] A session key is then calculated (Step 120). The changed transaction token is then encrypted using the session key to form an encrypted transaction token (Step 122).
    [0086] A financial transaction protocol message is then compiled, which comprises the encrypted transaction token and other communication requirements required by the selected transport channel (Step 124).
    [0087] It should be noted here that the initial transaction token may include a user's PIN. In these circumstances, the PIN is encrypted using a separate key for it, used to encrypt the transaction token.
    [0088] The financial transaction protocol message is then sent to the administrative processing system through a selected transport channel, as previously determined (Step 126).
    [0089] According to a second preferred embodiment of the invention, where like numerals refer to like parts, there is a method of executing a financial transaction 200.
    [0090] In this second embodiment, the terminal unit 14 is a mobile communication device 202. The mobile communication device 202 incorporates a SIM card interface 204 for receiving and retaining, with release possibility, a SIM card 206.
    [0091] In this embodiment, the SIM card 206 takes the form of at least one integrated circuit formed in a physical medium. The at least one integrated circuit has erasable memory means stored on it for storing executable software code. In this embodiment, the executable software code of the at least one integrated circuit is directed to two different functions - communications functionality and PSAM functionality. The executable software code stored on the at least one integrated circuit functions so as to provide the core functionality of its respective purpose (ie, communications functionality or PSAM functionality, as appropriate).
    [0092] The physical medium is similar in size and shape to other SIM cards (not shown), and similarly, has contacts in similar positions. The contacts press and enable communication between SIM card 206 and SIM card interface 204, when SIM card 206 is held in place with the possibility of being released.
    [0093] In this way, the interaction of the software stored on the SIM card 206 directed towards the communication functionality and free software stored on the mobile communications device 202 allows the mobile communications device 202 to communicate in accordance with normal mobile telephone devices (or their equivalents). This includes providing the ability to send SMS messages. Hereafter in this document this will be referred to as the SIM application.
    [0094] Similarly, the interaction of the software stored on the SIM card 206 directed towards the PSAM functionality and the free software stored on the mobile communication device 202 allows the mobile communication device 202 to function as a PSAM. Thus, when the PSAM functionality is initiated, the mobile communications device interface 202 functions as the PSAM interface. Hereinafter this will be referred to as payment application.
    [0095] The method of this second embodiment is now described as follows.
    [0096] The user operates the mobile communication device 202 as necessary to initiate the payment application execution (Step 250). Once started, the payment application functions to create a new logical communications channel between the device code part 202 and the code part stored in the SIM card 206 (Step 252). This is necessary to prevent the SIM application from interrupting the normal operating procedure.
    [0097] The logical communications channel remains open until the payment application closes it.
    [0098] The user then navigates through the payment application user interface in order to instruct the payment application that a new financial transaction is being created (Step 254).
    [0099] When an indication is made that a new financial transaction is to be created, the payment application asks the user for the type of the new financial transaction (Step 256) . The user has the option to specify one of the following types of financial transactions:
    [00100] Transaction request;
    [00101] Transaction replay request; and
    [00102] Transaction rollback request.
    [00103] As the form of each of these types of financial transactions is dictated by the transport channel used, the method of this embodiment of the invention will now be discussed purely in the context of a transaction request.
    [00104] After specifying that the new financial transaction is a transaction request, the terminal unit works to collect data related to the transaction (Step 258). This information comes from four sources:
    [00105] The payment application itself;
    [00106] The SIM card file system 206;
    [00107] The customer's credit/debit card; and/or
    [00108] When processing rules so determine, an STK session.
    [00109] For purposes of this embodiment, the customer's credit/debit card information is obtained through a card reader incorporated into, or otherwise connected to, the mobile communications device 202.
    [00110] Furthermore, as a way of explaining this aspect of the invention, the processing rules demand that a PIN be entered via an STK session (Step 260).
    [00111] Obtaining a PIN through an STK session is done by the SIM application, as is known by the technicians in the field. However, as soon as an STK session starts, the communication between the payment application and the SIM application receives an error message to indicate that the SIM card is busy with an STK session.
    [00112] Once the PIN has been retrieved through the STK session, the PIN is formatted as an ISO-0 PIN block (Step 262). The formatted PIN block is then encrypted using a unique use key (Step 264). In this embodiment, the encryption is triple DES encryption within the internal CBC mode that uses three different keys.
    [00113] Once all necessary and relevant information is obtained, the information is gathered and used to form a transaction token. However, before the transaction token can be properly constructed, the administrative financial transaction transport channel must be determined. In this configuration, two alternative transport channels are available:
    [00114] GPRS; or
    [00115] SMS
    [00116] GPRS is the preferred transport channel and as such a check is first made by the payment application to determine if the financial transaction can be communicated via GPRS (Step 266). If so, an initial transaction token is created, with the same structure described in the first realization of the invention (Step 268).
    [00117] The initial transaction token is then populated in accordance with the method 2 requirements of ISO 7816-4/ISO 9797-1 (Step 270). An administration token record data value is then appended to the populated token before continuing to populate the token with the fewest null values until the changed token is a multiple of 8 bytes (Step 272).
    [00118] A 128-bit message authentication code session key is then calculated (Step 274). The changed token is then encrypted using the authentication code session key to form an encrypted transaction token (step 276). In this configuration, the encryption techniques used are DES-based algorithms.
    [00119] A key serial number is then created as well (Step 278). The key serial number is an 80-bit value.
    [00120] The financial transaction protocol message is then compiled with the key serial number, forming the first element of the protocol message, followed by the transaction token and finally the message authentication code session key (Step 280 ).
    [00121] Alternatively, if it is not possible to communicate the financial transaction via GPRS, the financial transaction protocol message is compiled as follows.
    [00122] The initial transaction token is created and populated in the same way described for a GPRS-based communication (Steps 268 and 270). However, as part of this process, a population counter and message counter are formed (Step 282). The completion counter and message counter are then appended to the message, forming an unencrypted message (Step 284). The unencrypted message is then encrypted, using an encryption key based on 3GPP TS 03.48 specifications (Step 286).
    [00123] An SMS header is then added as a precursor to the encrypted message, forming a financial transaction protocol message ready to be sent (Step 288).
    [00124] It should be noted here that the initial transaction token may include a user PIN. In these circumstances, the PIN is encrypted using a separate key other than the one used to encrypt the transaction token.
    [00125] The financial transaction protocol message is then sent to the administrative processing system using the appropriate transport channel as determined above (Step 290). In the case of communication via SMS message, this involves passing the message to the SIM application for transmission.
    [00126] Upon receiving a financial transaction protocol message via the GPRS transport channel, the processing administrative system first confirms the message authentication code with reference to the message authentication code session key (Step 292). If the message authentication code cannot be confirmed, the financial transaction protocol message is disregarded and no further processing takes place (Step 294). However, as the inability to commit the financial transaction protocol message may result from transmission errors or corrupted data, the transaction is not terminated. The processing administrative system merely waits for the message to expire and the terminal unit to initiate a retry message.
    [00127] Once confirmed, the financial transaction protocol message is decrypted and forwarded to the receiving network (Step 296).
    [00128] In the case of financial transaction protocol messages sent via the SMS transport channel, it is assumed that an SMSC to which the message is sent decrypts the financial transaction protocol message before forwarding it to the administrative system processing (Step 298). The administrative processing system then forwards the decrypted message to the receiving network (Step 300).
    [00129] A method and equipment constructed according to this embodiment of the invention have advantages over other embodiments. In particular, as experts on the subject would note, this achievement solves problems such as:
    [00130] The vulnerability of normal SIMs;
    [00131] The limited available memory for a SIM to use during processing.
    [00132] The even more limited SIM memory available for use by other applications (such as the payment application); and
    [00133] The large form factor required by existing units that incorporate PSAM and SIM functionality.
    [00134] It should be noted by those skilled in the art that the above invention is not limited to the described embodiment. In particular, the following modifications and improvements can be made without departing from the scope of the present invention:
    [00135] Forms of unsecured public telecommunications infrastructure with which the invention as described above can be implemented include: existing wired telephone systems; the Internet. Consequently, the insecure public telecommunication infrastructure can be a wired or wireless telecommunication system.
    [00136] The structure and codes used for the formation of the bitmap and data elements vary according to the need of the implemented system. Consequently, any combination of structure and code can be used with the inventions described above.
    [00137] The form of encryption used is subject only to the restrictions of the means of transport and the desired level of security to be adopted. For example, if the application in question requires message authentication, the encryption technique used for the message authentication code might be ISO 9797-1 algorithm 3, using the DES algorithm in CBC mode.
    [00138] It is preferable that the PIN block be encrypted using the 3DES-CBC/CMAC encryption standard.
    [00139] It is preferable that the encryption of the transaction token as a whole is the 3DES-CBC/CMAC encryption standard, in which the transport medium is GPRS and GSM 03.48, in which the transport medium is SMS.
    [00140] A third encryption envelope can be used to provide security for an encrypted transaction token.
    [00141] Existing public keys can be used for encryption and authentication of the token as a whole, but the PIN must be encrypted using a separate, private and exclusive-use key.
    [00142] The user interface of terminal unit 14 can be any of the following: a dedicated physical keyboard; a touchscreen keyboard; a digital pen combined with character recognition software or handwriting.
    [00143] When the terminal unit 14 is not exclusive for processing transactions, the processing application may need to set up secure communication channels within the terminal unit 14 itself, to resolve security issues.
    [00144] An additional secure logic communications channel can be configured between the SIM application and the payment application when deemed necessary.
    [00145] Processing rules also determine the number of attempts that can be allowed to enter a valid PIN.
    [00146] The number of times a transaction retry request can be submitted against an initial transaction request is also determined by processing rules.
    [00147] Information related to the transaction can be obtained automatically through a card reader or similar, or can be obtained indirectly by entering details by the customer, related to the credit/debit card, in the terminal unit 14.
    [00148] The user's credit/debit card can be a magnetic stripe card, a smart card such as an RFID card, near field communication data reader, or similar. The invention only requires that an appropriate reader, or input device for entering credit/debit card related information can be incorporated as part of the terminal unit 14.
    [00149] Although the invention has been described in the context of cash transactions, the invention should not be considered limited to such transactions. The invention can also be easily used to process transactions involving credits, values, points or other mechanisms used by merchants to conduct a transaction (including loyalty and rewards schemes).
    [00150] Credit, debit and other banking applications that can run on the SIM card 206 can operate in conjunction with the PSAM functionality of the SIM card 206 to perform various financial transactions that are not otherwise described in this specification.
    [00151] Although the invention is contemplated as being widely used with devices whose functions revolve around a built-in SIM card 204 interface, the invention can also be used with any device that is otherwise connected to an adapter that incorporates this SIM card interface 204.
    [00152] It should be further noted by those skilled in the art that one or more of the above modifications or improvements, not being mutually exclusive, may still be combined, forming other embodiments of the present invention.
    权利要求:
    Claims (20)
    [0001]
    1. METHOD (100) OF EXECUTING A FINANCIAL TRANSACTION THROUGH AN UNSAFE PUBLIC TELECOMMUNICATION INFRASTRUCTURE, the method (100) being executed by a communications device (202) and characterized by comprising the steps of: obtaining a type of transaction user-specified financial transaction via a communications device user interface (202), the user-specified financial transaction type being a transaction request, a transaction retry request, or a transaction reversal request; then collect related data obtained by the user's specified financial transaction type; wherein the collected data includes at least a personal identification number, PIN; encrypt the PIN using a PIN key; building a transaction token that includes at least one financial transaction type and encrypted PIN; transaction token encryption constructed using a session key, where the session key is different from the PIN key; creating a transaction protocol message comprising the encrypted transaction token as dependent on a selected transport channel over which the message is to be transmitted; and transporting the financial transaction protocol message through the use of the selected transport channel and via an insecure public telecommunication infrastructure to a destination where the financial transaction protocol message will continue to be processed.
    [0002]
    2. METHOD (100), according to claim 1, characterized in that the type of financial transaction is obtained after being instructed that a new financial transaction must be created.
    [0003]
    3. METHOD (100), according to claim 1, characterized in that the step of collecting data related to a specific type of transaction includes the sub-step of collecting authentication data, which are later encrypted, and the token of Subsequently formed transaction includes the encrypted authentication data.
    [0004]
    4. METHOD (100), according to claim 3, characterized in that it includes the step of formatting the authentication data.
    [0005]
    5. METHOD (100), according to claim 1, characterized in that the step of collecting data related to a specific type of financial transaction includes obtaining data by at least one of the following ways: from files stored on a device used for get the data; a data reader associated or integrated with the device used to obtain the data; from a client, through the user interface of the device used to obtain the data.
    [0006]
    6. METHOD (100), according to claim 1, characterized in that the step of collecting data related to a specific type of financial transaction includes obtaining a set of transaction rules applicable to the type of financial transaction.
    [0007]
    7. METHOD (100), according to claim 1, characterized in that it also includes the step of filling the transaction token as required for the selected transport channel.
    [0008]
    8. METHOD (100), according to claim 1, characterized in that it also includes the step of calculating the session key, before the step of encrypting the transaction token.
    [0009]
    9. METHOD (100), according to claim 1, characterized in that the selected transport channel is the GPRS.
    [0010]
    10. METHOD (100), according to claim 9, characterized in that the step of creating a transaction token includes the sub-steps of: attaching an administration token record data value to the transaction token; and pad the transaction token with null values until the changed transaction token is an 8-byte multiple
    [0011]
    11. METHOD (100), according to claim 10, characterized in that the step of encrypting the transaction token also includes the sub-steps of calculating a message authentication code session key and encrypting the altered and filled transaction token using the message authentication code session key.
    [0012]
    12. METHOD (100) according to claim 11, characterized in that when the step of creating a financial transaction protocol message includes the sub-step of creating a serial key number, and where the financial protocol message is created in this way it comprises the serial key number, the transaction token and a message authentication code session key.
    [0013]
    13. METHOD (100), according to claim 1, characterized in that the selected transport channel is SMS.
    [0014]
    14. METHOD (100), according to claim 13, characterized in that the transaction token construction step also includes the sub-steps of determining a filling counter and a message counter, and attaching the filling counter and the message counter to message.
    [0015]
    15. METHOD (100), according to claim 14, characterized in that the transaction token encryption step includes the transaction token encryption sub-step using an encryption key based on 3GPP TS 03.48 specifications.
    [0016]
    16. METHOD (100), according to claim 13 or 14, characterized in that the step of creating a financial transaction protocol message includes the sub-step of prefixing the encrypted transaction token with an SMS header.
    [0017]
    17. COMMUNICATIONS DEVICE (202) TO FACILITATE THE EXECUTION OF A FINANCIAL TRANSACTION THROUGH AN UNSAFE PUBLIC TELECOMMUNICATION INFRASTRUCTURE, characterized in that this communications device (202) is operable to run software stored on it or on removable media in data communication and control with the device, to obtain a user-specific financial transaction type through a communications device user interface (202), the user-specific financial transaction type being a transaction request, a repeat transaction request or a transaction reversal request; then collect data relating to the type of user-specific financial transaction obtained; wherein the collected data includes at least a personal identification number, PIN; encrypt the PIN using a PIN key construct a transaction token that includes at least one financial transaction type and the encrypted PIN; encrypt the construction of the transaction token using a session key, where the session key is different from the PIN key; create a financial transaction protocol message comprising the encrypted transaction token as dependent on a selected transport channel over which the message is to be transported; and transporting the financial transaction protocol message using the selected transport channel and via the insecure public telecommunication infrastructure to a destination where the financial transaction protocol message will continue to be processed.
    [0018]
    18. COMMUNICATIONS DEVICE (202), according to claim 17, characterized in that the collected data include authentication data, and in which the transaction token includes the authentication data in encrypted form.
    [0019]
    A COMMUNICATION DEVICE (202) according to claim 17, further including a reader to read information stored in external devices.
    [0020]
    20. COMMUNICATIONS DEVICE (202), according to claim 17, characterized in that the communications device is operable to communicate via one or more of the following transport channels: GPRS; SMS.
    类似技术:
    公开号 | 公开日 | 专利标题
    BR112013011299B1|2021-05-18|method of executing a financial transaction over an unsecured public telecommunications infrastructure and communications device to facilitate the execution of a financial transaction over an unsecured public telecommunications infrastructure
    RU2631983C2|2017-09-29|Data protection with translation
    US10650371B2|2020-05-12|System and method for enabling a mobile communication device to operate as a financial presentation device
    US20140358777A1|2014-12-04|Method for secure atm transactions using a portable device
    CN108093001B|2021-02-19|System, method and server computer for mutual mobile authentication using key management center
    US20200372503A1|2020-11-26|Transaction messaging
    WO2017162164A1|2017-09-28|Electronic signature device transaction method
    AU2014256438B2|2016-11-24|A card for use in a method of performing a financial transaction via unsecured public telecommunication infrastructure
    BRPI1100931A2|2014-01-07|METHOD AND SYSTEM FOR VALIDATING A CORRESPONDING TRANSACTION TRANSACTION, TERMINAL AND PROGRAM
    JP2015146187A|2015-08-13|Method of performing financial transaction via unsecured public telecommunication infrastructure and apparatus for the same
    RU2681372C1|2019-03-06|Pos-terminal network control system
    ES2792986T3|2020-11-12|Method and system for communication of a terminal with a secure element
    同族专利:
    公开号 | 公开日
    UA109462C2|2015-08-25|
    CA2929167C|2019-08-13|
    KR101562051B1|2015-11-18|
    KR101579214B1|2015-12-23|
    US20160328708A1|2016-11-10|
    JP2013546078A|2013-12-26|
    TW201531082A|2015-08-01|
    EP2638661A1|2013-09-18|
    MX2013005255A|2013-07-05|
    RU2571733C2|2015-12-20|
    ZA201303885B|2014-11-26|
    KR20140130515A|2014-11-10|
    TWI581600B|2017-05-01|
    KR20130117803A|2013-10-28|
    CA2817212C|2016-08-23|
    CA2929167A1|2012-05-18|
    EP2638661A4|2017-06-07|
    WO2012064280A1|2012-05-18|
    MX337799B|2016-03-18|
    US20130226815A1|2013-08-29|
    CN103201758A|2013-07-10|
    TW201225602A|2012-06-16|
    AU2010363671A1|2013-04-18|
    AR083833A1|2013-03-27|
    CA2817212A1|2012-05-18|
    EP2638661B1|2020-07-08|
    AU2010363671B2|2014-11-27|
    SG189858A1|2013-06-28|
    EP3226465A1|2017-10-04|
    JP5867752B2|2016-02-24|
    BR112013011299A2|2020-05-26|
    TWI517644B|2016-01-11|
    RU2013126419A|2014-12-20|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US7248719B2|1994-11-28|2007-07-24|Indivos Corporation|Tokenless electronic transaction system|
    US5889863A|1996-06-17|1999-03-30|Verifone, Inc.|System, method and article of manufacture for remote virtual point of sale processing utilizing a multichannel, extensible, flexible architecture|
    US5850446A|1996-06-17|1998-12-15|Verifone, Inc.|System, method and article of manufacture for virtual point of sale processing utilizing an extensible, flexible architecture|
    US5943424A|1996-06-17|1999-08-24|Hewlett-Packard Company|System, method and article of manufacture for processing a plurality of transactions from a single initiation point on a multichannel, extensible, flexible architecture|
    US5812668A|1996-06-17|1998-09-22|Verifone, Inc.|System, method and article of manufacture for verifying the operation of a remote transaction clearance system utilizing a multichannel, extensible, flexible architecture|
    US6002767A|1996-06-17|1999-12-14|Verifone, Inc.|System, method and article of manufacture for a modular gateway server architecture|
    US5983208A|1996-06-17|1999-11-09|Verifone, Inc.|System, method and article of manufacture for handling transaction results in a gateway payment architecture utilizing a multichannel, extensible, flexible architecture|
    US7039809B1|1998-11-12|2006-05-02|Mastercard International Incorporated|Asymmetric encrypted pin|
    JP2000341263A|1999-05-27|2000-12-08|Sony Corp|Information processing device and its method|
    JP2001344537A|2000-05-31|2001-12-14|Ntt Docomo Inc|Electronic value system, communication terminal and server|
    US6891953B1|2000-06-27|2005-05-10|Microsoft Corporation|Method and system for binding enhanced software features to a persona|
    US7010808B1|2000-08-25|2006-03-07|Microsoft Corporation|Binding digital content to a portable storage device or the like in a digital rights management system|
    US7203657B1|2000-09-05|2007-04-10|Noam Eli M|General packet-based payment and transaction method and system|
    AU7096401A|2000-10-24|2002-05-06|Nds Ltd|Transferring electronic content|
    US7103576B2|2001-09-21|2006-09-05|First Usa Bank, Na|System for providing cardless payment|
    CN1410922A|2001-09-27|2003-04-16|行毅科技股份有限公司|Vehicle radio trade system and its method|
    CA2481872A1|2002-04-28|2003-11-13|Paycool International Limited|System to enable a telecom operator provide financial transactions services and methods for implementing such transactions|
    RU2371877C2|2002-04-28|2009-10-27|Пэйкул Интернэшнл Лимитед|System allowing operator to render services of financial transactions, and methods of implementing such transactions|
    US7254608B2|2002-10-31|2007-08-07|Sun Microsystems, Inc.|Managing distribution of content using mobile agents in peer-topeer networks|
    TW200409521A|2002-11-28|2004-06-01|Lohmac Pte Ltd|Authentication and identification system and transactions using such an authentication and identification system|
    AU2004252925B2|2003-06-30|2006-10-26|Selvanathan Narainsamy|Transaction verification system|
    CA2540098A1|2003-09-24|2005-03-31|Magian Design Studio Pty Ltd|Method and system for management and publication of media assets in a distributed network|
    US7301501B2|2003-10-10|2007-11-27|Option|Telecommunications card for mobile telephone network and wireless local area network|
    UA74105C2|2004-06-29|2005-10-17|Close Joint Stock Company Comm|Method of carrying out settlements by electronic facilities|
    ES2263344B1|2004-07-30|2007-11-16|Jose Ignacio Bas Bayod|METHOD FOR PERFORMING SECURE PAYMENT OR COLLECTION TRANSACTIONS, USING PROGRAMMABLE MOBILE PHONES.|
    WO2006053191A2|2004-11-10|2006-05-18|Mastercard International Incorporated|Method and system for performing a transaction using a dynamic authorization code|
    CN1321537C|2004-11-29|2007-06-13|上海市电信有限公司|Electronic paymenting service system and realizing method based on fixed telephone net short message|
    US7818585B2|2004-12-22|2010-10-19|Sap Aktiengesellschaft|Secure license management|
    CA2596257C|2005-01-28|2016-05-17|Cardinal Commerce Corporation|System and method for conversion between internet and non-internet based transactions|
    US8682795B2|2005-09-16|2014-03-25|Oracle International Corporation|Trusted information exchange based on trust agreements|
    JP2007114404A|2005-10-19|2007-05-10|Matsushita Electric Ind Co Ltd|Data processing device and method|
    US20070106564A1|2005-11-04|2007-05-10|Utiba Pte Ltd.|Mobile phone as a point of sale device|
    US20070125840A1|2005-12-06|2007-06-07|Boncle, Inc.|Extended electronic wallet management|
    US20070130463A1|2005-12-06|2007-06-07|Eric Chun Wah Law|Single one-time password token with single PIN for access to multiple providers|
    KR100746030B1|2006-02-06|2007-08-06|삼성전자주식회사|Method and apparatus for generating rights object with representation by commitment|
    US7900060B2|2006-02-17|2011-03-01|Vudu, Inc.|Method and system for securing a disk key|
    WO2008030397A2|2006-09-05|2008-03-13|Mobibucks, Inc.|Payment systems and methods|
    US20080275799A1|2006-10-08|2008-11-06|Randazza Joseph R|Payment systems and methods|
    KR101086420B1|2006-12-22|2011-11-23|삼성전자주식회사|Method and apparatus for decoding right-object and method and apparatus for sharing contents using it|
    KR100871425B1|2006-12-22|2008-12-03|이노시드 주식회사|Payment system|
    US20080201226A1|2006-12-26|2008-08-21|Mark Carlson|Mobile coupon method and portable consumer device for utilizing same|
    SG147345A1|2007-05-03|2008-11-28|Ezypay Pte Ltd|System and method for secured data transfer over a network from a mobile device|
    CN201117020Y|2007-08-24|2008-09-17|中兴通讯股份有限公司|Mobile terminal end with wireless POS machine function|
    CN101547239B|2008-03-26|2012-04-04|威海市卡尔电气研究所|Intelligent electronic payment public phone|
    US20090281949A1|2008-05-12|2009-11-12|Appsware Wireless, Llc|Method and system for securing a payment transaction|
    US20090307140A1|2008-06-06|2009-12-10|Upendra Mardikar|Mobile device over-the-air registration and point-of-sale payment|
    US8929877B2|2008-09-12|2015-01-06|Digimarc Corporation|Methods and systems for content processing|
    WO2010042560A2|2008-10-06|2010-04-15|Vivotech, Inc.|Systems, methods, and computer readable media for payment and non-payment virtual card transfer between mobile devices|
    SK288747B6|2009-04-24|2020-04-02|Smk Kk|Method and system for cashless payment transactions, particularly with contactless payment device using|
    US9118462B2|2009-05-20|2015-08-25|Nokia Corporation|Content sharing systems and methods|
    US8811969B2|2009-06-08|2014-08-19|Qualcomm Incorporated|Virtual SIM card for mobile handsets|
    US8453226B2|2010-07-16|2013-05-28|Visa International Service Association|Token validation for advanced authorization|
    US8625788B2|2011-01-05|2014-01-07|Intel Corporation|Method and apparatus for building a hardware root of trust and providing protected content processing within an open computing platform|
    US8560453B2|2011-06-30|2013-10-15|Intel Corporation|Method and apparatus for dynamic, real-time ad insertion based on meta-data within a hardware based root of trust|
    WO2013085517A1|2011-12-08|2013-06-13|Intel Corporation|Method and apparatus for policy-based content sharing in a peer to peer manner using a hardware based root of trust|
    EP2801061B1|2012-01-05|2020-08-26|Visa International Service Association|Data protection with translation|
    CN104239803B|2013-06-06|2017-08-25|中国银联股份有限公司|The safety information interaction method shifted for e-sourcing|
    US10366391B2|2013-08-06|2019-07-30|Visa International Services Association|Variable authentication process and system|TWI460676B|2012-07-24|2014-11-11|Telecom preferential program shelves management platform|
    WO2014087381A1|2012-12-07|2014-06-12|Visa International Service Association|A token generating component|
    EP3078220A4|2013-12-02|2017-05-17|Mastercard International Incorporated|Method and system for secure tranmission of remote notification service messages to mobile devices without secure elements|
    CA2933336C|2014-04-14|2018-09-04|Mastercard International Incorporated|Method and system for generating an advanced storage key in a mobile device without secure elements|
    US20160005035A1|2014-07-02|2016-01-07|Mistral Mobile|Secure financial transaction using plain text sms|
    TWI501202B|2014-07-11|2015-09-21|Proeasy Network Solutions Co Ltd|Method and system for automatically collecting inspection records|
    US10484345B2|2014-07-31|2019-11-19|Visa International Service Association|System and method for identity verification across mobile applications|
    US9999924B2|2014-08-22|2018-06-19|Sigma Labs, Inc.|Method and system for monitoring additive manufacturing processes|
    US9721242B2|2014-10-28|2017-08-01|Poynt Co.|Payment terminal operation method and system therefor|
    USD762766S1|2014-10-28|2016-08-02|Poynt Co.|Payment terminal|
    WO2016115284A1|2015-01-13|2016-07-21|Sigma Labs, Inc.|Material qualification system and methodology|
    WO2016134117A1|2015-02-20|2016-08-25|Samsung Pay, Inc.|Detachable electronic payment device|
    US10207489B2|2015-09-30|2019-02-19|Sigma Labs, Inc.|Systems and methods for additive manufacturing operations|
    CN105303695B|2015-10-19|2018-01-19|东方通信股份有限公司|A kind of cabinet face service equipment and its method of work|
    US10182044B1|2015-12-03|2019-01-15|Amazon Technologies, Inc.|Personalizing global session identifiers|
    US10277569B1|2015-12-03|2019-04-30|Amazon Technologies, Inc.|Cross-region cache of regional sessions|
    US9900160B1|2015-12-03|2018-02-20|Amazon Technologies, Inc.|Asymmetric session credentials|
    US9894067B1|2015-12-03|2018-02-13|Amazon Technologies, Inc.|Cross-region roles|
    US10055053B2|2016-10-03|2018-08-21|Poynt Co.|System and method for disabled user assistance|
    法律状态:
    2020-06-02| B15K| Others concerning applications: alteration of classification|Free format text: AS CLASSIFICACOES ANTERIORES ERAM: H04L 9/32 , G06Q 40/00 Ipc: H04L 9/32 (2006.01), G06Q 20/38 (2012.01) |
    2020-06-09| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|
    2020-07-14| B25D| Requested change of name of applicant approved|Owner name: EINNOVATIONS HOLDINGS PTE. LTD. (SG) |
    2021-03-09| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|
    2021-05-18| B16A| Patent or certificate of addition of invention granted|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 10/11/2010, OBSERVADAS AS CONDICOES LEGAIS. PATENTE CONCEDIDA CONFORME ADI 5.529/DF |
    优先权:
    申请号 | 申请日 | 专利标题
    PCT/SG2010/000427|WO2012064280A1|2010-11-10|2010-11-10|Method of performing a financial transaction via unsecured public telecommunication infrastructure and an apparatus for same|
    [返回顶部]